近期看到几篇公众号文章吐槽敏捷方法，称“敏捷最大的贡献就是刺激了白板和N次贴纸的销量”、“拥抱变化快速适应变成了无止境的需求变更”、“复盘会议像是一个展开批评与自我批评的精神刑场”，当然这些文章还都是从工程师或者员工角度发表的观点，从管理者角度看到的却是员工实质上很难理解、接受和落地各种敏捷方法，甚至于产品的生产效果还没有当初好，员工背后怨声载道。
而与此同时，在企业中实实在在的正在发生着什么？
拿鹅厂曾经的某个部门的运作来举例：迭代初始产品经理将确认的需求列表（Backlog）与团队进行需求评审，项目经理根据工程师的评估将需求按优先级从末砍起直到剩余需求可在大约一个月周期（Sprint）内完成，每天晨会大家互相同步目前进度、遇到问题以及所需支持，大约每3-5个工作日工程师就会开开心心地拉产品经理、设计、测试测试目前进度上产出的 demo（Show Case），并将反馈的问题进行快速解决。当然即使是鹅厂，项目也会时不时遇到延期情况，但他们从来不把“延期”本身当作一种“问题”，而是通过复盘找出导致延期的原因，并在接下来的迭代中加以改进；需求变更也会有但是很少，而且每次变更都要产品总监、开发总监和项目经理的一致确认。列表需求的开发进度和质量经项目经理监督、跟进并满足发布条件（测试用例通过）时，及时发布上线（Release & Deployment）。
从他们的工作流程上看，的的确确就是敏捷开发所倡导的那些方法，顶多名字不太一样；如果你问每一个员工，他们只会表示“这种工作流程难道不是自然而然的么？我从上班第一天起就是这种节奏，挺好的啊。”
除此之外，与敏捷源于近似理念、相互配合的这些产物也正在大放光辉：
- DevOps 连续多年被 ThoughtWorks 推崇，华为更是在 K8S 的开发上不遗余力。
- 发源于 Google 的 OKR 也正在各个公司大行其道。
- Trello、Teambition 等基于敏捷迭代的项目管理工具越来越多被大中小企业和团队所应用。
- Github 和 Gitlab 也不断地把看板工具、任务管理工具、CI/CD 等内化到其平台上。面对着如上这些事实，我不知道是谁才会有这么强烈的自信喊出「敏捷已死」的口号。
可为什么到了你的团队里，这些就行不通了呢？
我其实想问的是——你和你的团队对于“敏捷”的理解是怎样的？它是一种方法论？一种工作流程？一种制度？如果你把它当做一种制度和方法论，把人套进去变成适应制度的工具，那只能说你对敏捷的理解基础就是错误的，也就别以讹传讹批判敏捷了。
敏捷关注的核心是“价值”，一切的起点是“以人为本”。它的目的是让人成为不断进行自我完善和团队完善的价值点，而不是拿一套方法论和制度去要求所有人运行在其中。敏捷本身就倡导和推崇团队不断将工作流程和制度进行优化改善，而不是固守。你的团队喜欢用 Jira，那就不需要用白板；你的员工对需求评估一致，那就不需要次次拿扑克牌表决；你的员工能在 OA 上把自己的工作安排透明化，那就不需要天天晨会。敏捷要改善的是“现存的不合理之处”，为什么你会觉得拘泥于某种固定的套路是敏捷想表达的？这是谁的问题？
如果作为一个员工的你认为“制度就是束缚人的”、“沟通是产品经理的事儿与我无瓜”、“复盘就是自己揭短给别人看”，那这不是敏捷的问题，是你的职业素养问题。工作是一件很理性客观充满未知和挑战的事情，我们的工作本质上就是试图去解决一个又一个的问题，不断去逼近我们的理想预期。制度是为了协调不同能力和认知的人保持对工作内容的一致评估，减少因差异性导致的主观分歧；一个本身拒绝沟通的人任谁再擅长沟通也无法对话；复盘是为了确认有效工作的正向反馈、暴露三不管地带并试图用制度去解决问题，而非针对个人的批判。
同样的，作为一个管理者，你为员工“敢于透明自己的进度、效率与问题”提供了足够的安全感、让他们知道不会因此而受到压迫或者惩罚了么？你推行某些制度的时候有考虑过自己要凌驾于其上还是与大家一同遵守了么（频繁变更需求真的是敏捷认可的么）？
对于从不思考的人来说，思考是一件很让人头疼的事情；同理，对于无意于不断进取的团队来说，敏捷也就是一件很让人讨厌的事情。你可以因为自己的不思进取而去选择一个不要求进步的团队工作，但如果你一边不思进取一边还想获得更多的回报那就太扯淡了，省省吧，别为自己的懒惰找借口，更别把锅甩到别处去。
笔者近期给一个团队做了为时半年的敏捷教练，在初始阶段从来不进行口号式的宣传“我们要用敏捷开发了”等等，笔者只是引导团队成员思考一系列问题——“我们目前在团队协作中遇到的问题都有哪些？”“这些问题的根源在于什么？”“用什么样的举措可以解决这些问题？”“我们应该如何让大家都认识到这个举措的意义、并一同将它维护成为我们的工作流程中的必要一环？”至于具体的解决方案，团队的成员身处一线，自然比笔者或者团队管理者更容易找到最优解。而笔者作为教练的角色，只需要确认其有效性、并时刻观察与跟进团队成员、一直到这些变成他们的工作习惯，笔者的任务就完成了。
例如，在面对“如何解决项目延期”的问题时，经过对团队工作习惯的深入观察和与团队成员的充分沟通，笔者辅助团队把问题根源定位在如下几个方面：
- 需求变更或新增导致工作量发生变化。
- 对探索型需求的开发效率预估过于乐观，忽略了衍生风险。
- 中间过程没有跟进与把控（时间与质量）。如果你对项目管理有所了解，你会发现这些问题其实都可以归因于——这个团队没有一个项目经理。最简单的方案当然是招一个项目经理——任何时候，招人解决问题当然都是最容易想到也最容易执行的。但不光是成本上让创业团队难以接受，实际上团队每新增一个人员，协调与沟通成本（我们俗称内耗）的指数形式增长，往往会直接打击到你最初的期望。笔者决定用敏捷思想解决这件事——让团队自组织化，于是做了如下举措：
- 遏制需求变更的来源——主要是克制老板试图自行出产品方案的欲望，转而放手给团队去确定解决方案，在需求评审通过时锁定需求，这个 Sprint 如果没有遇到紧急事件（如当机、Crash 率奇高、没有有效解决方案）的话将不允许新增或变更需求，新增需求放入 Backlog 在下个 Sprint 时再进行评估。
- 探索型需求用“渐进明细”的方式展开，说白了第一次需求评审确定做哪些需求，然后团队确定用几天时间来确认解决方案和设计模式，然后通过第二次需求评审来准确评估开发工期。
- 考虑到开发人员开始的主动沟通欲望不强，初期由产品经理每天或每隔天收集进度并在开发小群进行同步，通过几个 Sprint 的刺激之后逐渐转化为由开发人员主动在群内概述阶段性进度。
- 每周一和周五团队全员进行进度回顾，并根据实际情况决定是否调整后续工期。在这样进行了两个月（两个 Sprint）之后，效果逐渐显示出来了：原本已经把自己放到「接任务的劳力」（相关人的原话如此）角色的工程师们开始在全员大群内主动发布当天合并代码后的 demo 版本并督促相关人给予体验反馈了；后续的几个版本中极少出现延期情况了；团队成员间的交流变多了，遇到问题时回避不语的情况变少了，等等等等。
当然，在这些你能看到的表面行为的背后其实还有很多“政治性工作”。笔者通过跟团队成员的私下一对一沟通，了解每个成员对团队目标的期望、肯定每个人所做的工作的价值、了解每个人的性格与喜好并据此协调团队中的沟通与协作方式，并通过外部的反馈（用户、老板、产品经理等）将这种”价值感“反馈给每一个成员，让他们切实感受到自己工作的一点一滴都是给他人带来意义和价值的。明确目标——过程渐进——持续反馈——收获价值，我不需要告诉团队敏捷是什么，我只需要让他们感受到改进过程中所获得的意义就足够了。
很多管理者会错误地执行了一条先喊口号再行推广的途径。事实上，什么是敏捷、敏捷该怎么做，这都是管理者（尤其项目经理）才应该理解的东西，是管理者/项目经理根据团队现在存在的问题，有所取舍地应用敏捷的方法与工具，带领团队一起培养起一系列的协作习惯。当团队成员发现有一些很小的方法和工具就能解决他们现在面临的问题时，他们自然会有兴趣去了解这背后的知识是什么——再次强调：自上而下推行制度，本来就不是敏捷所提倡的！
顺便纠正一下管理者其他的一些错误甚至可笑的思维：
- 敏捷就是拥抱变化，所以即使有需求变更也应该快速响应并且接受——在一个 Sprint 只有一个月甚至两周的节奏之下，需求变更意味着决策者在两周内就推翻了自己曾经信誓旦旦的方案，所以问题出在谁身上？市场变化再快，会快到让你两周变更一次决策么？
- 创业团队没有管理就是最好的管理——「没有管理」是个理想状态，前提是所有人相互配合默契、信息透明共享，士兵要打仗还要经过假以时日的训练与磨合呢，你的团队能做到在不加管理的状态下自由磨合从而发挥出1+1=2甚至>2的功效么？我是不太相信的。
- 我应聘你就是让你来解决问题的，所以不要拿问题来找我——巧妇也难为无米之炊，篇篇能写 10w+ 爆款的人为什么要给你打工？不花钱能拉几万新用户的运营为什么要给你打工？员工有问题找你是需要获得你在更高层面的资源和关系上的帮助，最终也是为了你的公司业绩，你为什么会觉得是这个员工有问题？
- 敏捷好说啊，开晨会、用钉钉、做冲刺！做不好就是人不行！——上面说了，敏捷的本质不是工具和方法论，它是一种价值观，抛却了「以人为本」的基础，任何组织都敏捷不起来。
- 感觉最近大家工作不积极啊，我们加班吧。——如果一个员工是混日子的，为什么面试和试用期你没有否决掉？如果员工都开始混日子了，那是谁出了问题？